Security Management in the Cloud - Security Vulnerability, Patch, and Configuration Management (part 2)

6. IaaS VPC Management

IaaS VPC management focuses on the CSP-managed infrastructure, as well as the customer infrastructure interfacing with the IaaS service. IaaS VPC management diverges from SaaS and PaaS in that the infrastructure delineation, network boundary between customers, and CSP infrastructure are blurred. For each layer of infrastructure (network, host, storage), the customer and CSP have responsibilities in managing VPC in the respective layers from their perspective (i.e., the CSP is responsible for the common CSP infrastructure available to all customers, and the customer is responsible for the virtual infrastructure available to the customer for the duration of use). Hence, a VPC management program should address both the common and shared infrastructures.

6.1. IaaS provider responsibilities

In general, an IaaS CSP is responsible for VPC management of the infrastructure that is owned and operated by the CSP, as well as the third-party infrastructure and services they may rely on. The VPC management scope should include:

• Systems, networks, hosts (hypervisors), storage, and applications that are CSP-owned and operated

• Systems, networks, hosts, storage, and applications that are managed by third parties

• The web console or management station used by customers to manage their virtual infrastructure

• Personal computers owned by the IaaS employees and contractors

6.2. IaaS customer responsibilities

IaaS customers are responsible for VPC management of the virtual infrastructure allocated by an IaaS CSP for customer use. The VPC management scope should include:

Virtual servers

This includes VMs that are active or dormant. The VPC management process of VMs must consider the OSs of the virtual servers and customize the program accordingly (e.g., Fedora Linux, Solaris 10, Windows 2003). Customers are advised to follow the standard practice in managing VMs, which includes:

Image standardization via a security-by-default approach

Customers are advised to standardize the image after sufficiently hardening it using the security-by-default approach. Loss of security by default is more apparent in the early days of cloud services, until experience and best practices catch up. The security-by-default concept is the implicit security existing in day-to-day operations.

Configuration standards

The OS, applications server, database, and web server must be installed and configured in accordance with least-privilege and security hardening principles to reduce their overall attack surface. For example, the Center for Internet Security publishes Internet security benchmarks for major OS, databases, and application servers based on recognized best practices for deployment, configuration, and operation of networked systems. The center’s security-enhancing benchmarks encompass all three factors in Internet-based attacks and disruptions: technology (software and hardware), process (system and network administration), and human (end user and management behavior).

Configuration management

This refers to centralized configuration management where the appropriate configuration information is necessary to manage a large number of nodes and zones in a public IaaS cloud. Numerous configuration management tools are available, including open source tools (e.g., Puppet) and tools from commercial vendors such as BMC, Configuresoft, HP, Microsoft, and IBM. However, configuration management of virtual servers hosted in the cloud will require customization per CSP, given the uniqueness of the CSP-specific management API.

Network access policies

Firewalling is heavily used to establish security zones for applications hosted in an IaaS cloud, and network zoning plays a large role in the security architecture. The configuration of network policies that permit traffic in and out of a customer infrastructure should be carefully managed to mitigate risk due to improper configuration. Improper configuration of network access policies can expose vulnerable services to crackers on the Internet. Policies are typically grouped into the following trust categories:

Internet policy

Allow traffic between customer virtual servers and hosts on the Internet (e.g., allow only ports 22, 80, and 443 to servers). Deny all outbound traffic initiated from customer virtual servers.

Zone policy

Allow traffic between virtual servers within the cloud (e.g., allow port 3306 [MySQL] from server zone A to server zone B).

Note:

Network policy management, mechanisms, and features are typically unique to an IaaS provider. Hence, you should familiarize yourself with your provider’s IaaS policy management features.

IaaS administrators are also responsible for VPC management of their systems that interface with an IaaS service. These systems include:

• Cloud management station, which is the host that the customer manages for managing the virtual infrastructure in an IaaS cloud

• Personal computers of IaaS administrators

• Browsers used for accessing the IaaS service

IaaS customers have options to leverage third-party services, such as RightScale, Enomaly, Elastra, and 3tera, to manage the deployment of their public and private IaaS clouds. However, the type of security management service will vary among providers, and you will have to work with your provider to include security management functions in your SLA.

7. Intrusion Detection and Incident Response

The multitenant delivery model of a large-scale cloud provider providing SaaS, PaaS, and IaaS services creates significant incident response and intrusion management challenges for both customers and CSPs. Intrusion and incident management are key functions within a corporate information security management domain to mange and mitigate risks, including loss of intellectual property, regulatory non-compliance, brand erosion, and fraud. These critical functions support security management and allow organizations to respond to intrusions and data breaches. Furthermore, organizations are legally obligated to comply with privacy data breaches. More than 44 U.S. states have adopted security breach disclosure laws that require the custodian of personal and regulated data to notify individuals whose data might have been compromised during a breach of security. Since public cloud computing by definition is multitenant and delivered to customers using shared infrastructure resources and services, both the customer and the CSP are responsible for managing intrusion and incident response. Both parties will need to be prepared to respond to and manage security breaches.

ISO 27002 provides the following control guidance for incident response and notification:

13.1 Reporting information security events and weaknesses Objective: To ensure information security events and weaknesses associated with information systems are communicated in a manner allowing timely corrective action to be taken.

Formal event reporting and escalation procedures should be in place. All employees, contractors and third party users should be made aware of the procedures for reporting the different types of event and weakness that might have an impact on the security of organizational assets. They should be required to report any information.

13.2 Management of information security incidents and improvements Objective: To ensure a consistent and effective approach is applied to the management of information security incidents.

Responsibilities and procedures should be in place to handle information security events and weaknesses effectively once they have been reported. A process of continual improvement should be applied to the response to, monitoring, evaluating, and overall management of information security incidents. Where evidence is required, it should be collected to ensure compliance with legal requirements.

Traditionally, medium and large enterprise customers managed security and incident monitoring processes either using an internal security operations center (SOC) or via a third-party managed service. A SOC today monitors events from firewalls and intrusion detection platforms and responds to incidents using a Computer Emergency Response Team (CERT) process. The cloud application deployment will challenge the traditional network security-monitoring model because those applications will no longer be protected by the monitored firewalls and IDS. The responsibility scope of intrusion monitoring and incident response in the cloud will depend on the SPI (SaaS, PaaS, IaaS) delivery model, CSP-specific SLA, incident disclosure policy, and data governance model within the CSP. Since the CSPs may host hundreds of thousands of virtual servers (IaaS), application instances (PaaS), and commingled customer data (SaaS), the scale of operation will challenge them in different ways. Can the CSP identify the scope of affected customers? And isolate security incidents to affected customers? And inform the affected customers within the time period dictated by the SLA or policy?

Incident notification in the cloud, however, is not as simple as current incident management processes followed by a SOC or CERT team. In the traditional model, those processes belong to a single governance and incident response model where one internal group handles the notification and remediation for all applications governed by the organization’s IT department. In the case of a cloud where thousands of application owners have a stake, the notification process is more complex and will not follow traditional methods. New incident response tools may need to emerge to manage the complexity—e.g., an application registry implemented by the CSPs, with the contact details of the application owners and an automated notification system to handle a large number of customers (tenants).

Best practices from a privacy perspective dictate the isolation of application data. In the traditional architecture, the breach management process will focus on one entity and not several. Unfortunately, in the cloud, the data separation will blur quickly and an incident procedure will have to be very specific to handling a commingled data environment and identify the dependencies so that the incident notification can be delivered to all parties in a line of data custody.

8. Customer Versus CSP Responsibilities

Given the shared infrastructure and responsibilities, both the customer and CSP should have in place a security incident response plan to address any kind of security breach thoroughly and expeditiously. The team should promptly disclose to other tenants the existence of a vulnerability that affects its operation to prevent further ripple effects (e.g., cascading infections within or outside the cloud). The serviced customer may have to inform its own customers or employees of the occurrence of the breach. The cloud service provider may also have to inform its other tenants that the breach has occurred.

In the case of an IaaS or a PaaS environment, the system and application trust boundary interlaces both the CSP and customer environment, and as a result, both parties share responsibilities for security monitoring and incident response domains. Those responsibilities should be clearly identified and documented. For example, a PaaS CSP should be responsible for intrusion detection and incident response for the shared network and system infrastructure, for the PaaS platform runtime engine software, and for supported service components; the customer is responsible for their deployed applications and hosted data.

The provider collects and must protect a huge amount of security-related data. For example, at the network level, the provider should be collecting, monitoring, and protecting firewall, intrusion prevention system (IPS), security incident and event management (SIEM), and router flow data. At the host level, the provider should be collecting system logfiles, and at the application level, SaaS providers should be collecting application log data, including authentication and authorization information. They should have in place a security monitoring and incident response plan to address the security breach thoroughly and expeditiously.

What data the CSP collects and how it monitors and protects that data is important to the provider for its own audit purposes (e.g., SAS 70). Additionally, this information is important to both providers and customers in case it is needed for incident response and any digital forensics required for incident analysis.

Table 1 summarizes the responsibilities of customers and CSPs for both intrusion detection and incident response functions.

9. Caveats

Prior to designing a VPC program, customers are advised to read and understand the terms and conditions and user agreements with their CSP, because there may be potential restrictions for scanning network services, brute force testing, and penetration testing of applications deployed on that CSP’s *aaS platform. Furthermore, network port scanning, application security scanning, and active penetration testing can trigger a CSP’s intrusion detection system/intrusion prevention system (IDS/IPS) alarms, which in turn can result in suspension or deactivation of your service temporarily or permanently. For example, Amazon AWS, as a matter of policy, prohibits port scanning of your virtual servers. According to the AWS security white paper,^[53] “Port scans by Amazon EC2 customers are a violation of the Amazon EC2 Acceptable Use Policy (AUP). Violations of the AUP are taken seriously, and every reported violation is investigated.”

^[53] See http://awsmedia.s3.amazonaws.com/pdf/AWS_Security_Whitepaper.pdf.